home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19941031-19941221
/
000381_news@columbia.edu_Fri Dec 9 14:17:50 1994.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
4KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA12039
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 9 Dec 1994 23:55:19 -0500
Received: by apakabar.cc.columbia.edu id AA19741
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 9 Dec 1994 23:55:17 -0500
Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Flow Control in MS-DOS Kermit 3.14
Message-Id: <1994Dec9.201750.35072@cc.usu.edu>
Date: 9 Dec 94 20:17:50 MDT
References: <3c2me7$d29@sundog.tiac.net> <1994Dec7.095922.34783@cc.usu.edu> <3c7enb$atf@sundog.tiac.net>
Organization: Utah State University
Lines: 53
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3c7enb$atf@sundog.tiac.net>, ciaraldi@max.tiac.net (Michael Ciaraldi) writes:
> Dear Joe,
> These (4 and 5) are two different cases, and they are different from 3.
> Each may be appropriate in certain situations, and I wanted to find
> out if Kermit supported them.
>
> Consider a VAX with a serial card that has large output buffers, as many do.
> If a terminal (or Kermit emulating one) just passes through
> ^S and ^Q characters (case 3), what happens when the user hits a ^S (XOFF)?
> It gets sent to the host. The host CPU detects it and stops sending data.
> However, there may be several thousand characters still in the
> output buffer of the serial card, and there is no mechanism for the
> host CPU to notify the card to stop sending. So, even though
> the user has hit ^S, several more pages of data appear on the screen
> and scroll off the top of the screen. I've seen this happen many times.
> Fortunately, MS-DOS Kermit has a screen scrollback buffer,
> but this is still a problem for most users
> (those who are not using Kermit, of course).
>
> In case 4 and 5, when the user hits ^S, Kermit would stop sending
> updates to the screen. It would just accumulate any incoming
> data from the host into a buffer, then send it to the screen later
> when the user hits ^Q. The difference between 4 and 5 is that
> in 5 the host also gets notified, so there is a chance that the buffer
> will not overflow.
In the user's manual is the keyboard verb \kholdscrn. That is
equivalent to DEC's HoldScreen key.
Accumulating into a buffer is what triggers almost all flow
control activity: it reaches a high or low water mark. For snappy
flow control response reduce the capacity of the comms channel. Too
much storage capacity will result in lost bytes, with no way to prevent
that from occuring (except buy a faster PC).
>
> On case 8, I asked because I was doing some tests on Kermit
> last week and found what I thought was funny behavior.
> I wired my PC to a Unix machine's serial port and used
> another comm program on the Unix machine to talk to that port.
> The Unix machine was set for no flow control.
> I gave the command SET FLOW XON to the PC Kermit,
> then did a TRANSMIT. The contents of the file started
> appearing in the window on my Unix machine.
> Then I hit a ^S on the Unix machine. The PC kept sending the file.
> Shouldn't Kermit have stopped sending the file until
> it received a ^Q?
I have no idea what the Unix machine actually sent, if anything.
Tell MS-DOS Kermit SET DEBUG ON and enter Connect mode to debug the
Unix side. MSK should respond to the XOFF, and when it has something
to send while blocked it will wait about 8-10 seconds before breaking
through and sending (a deadlock prevention mechanism).
Joe D.